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Abstract. Recent work has proposed a promising approach to improving 
scalability of program synthesis by allowing the user to supply a syntactic 
template that constrains the space of potential programs. Unfortunately, 
creating templates often requires nontrivial effort from the user, which 
impedes the usability of the synthesizer. We present a solution to this 
problem in the context of recursive transformations on algebraic data¬ 
types. Our approach relies on polymorphic synthesis constructs', a small but 
powerful extension to the language of syntactic templates, which makes it 
possible to define a program space in a concise and highly reusable manner, 
while at the same time retains the scalability benefits of conventional 
templates. This approach enables end-users to reuse predefined templates 
from a library for a wide variety of problems with little effort. The paper 
also describes a novel optimization that further improves the performance 
and the scalability of the system. We evaluated the approach on a set of 
benchmarks that most notably includes desugaring functions for lambda 
calculus, which force the synthesizer to discover Church encodings for 
pairs and boolean operations. 


1 Introduction 


Recent years have seen remarkable advances in tools and techniques for automated 
synthesis of recursive programs |8llll3l4ll6j . These tools take as input some form 
of correctness specification that describes the intended program behavior, and a 
set of building blocks (or components). The synthesizer then performs a search 
in the space of all programs that can be built from the given components until 
it finds one that satisfies the specification. The biggest obstacle to practical 
program synthesis is that this search space grows extremely fast with the size of 
the program and the number of available components. As a result, these tools 
have been able to tackle only relatively simple tasks, such as textbook data 
structure manipulations. 

Syntax-guided synthesis (SyGuS) [2] has emerged as a promising way to 
address this problem. SyGuS tools, such as Sketch m and Rosette renrni 
leverage a user-provided syntactic template to restrict the space of programs the 
synthesizer has to consider, which improves scalability and allows SyGus tools to 





tackle much harder problems. However, the requirement to provide a template 
for every synthesis task significantly impacts usability. 

This paper shows that, at least in the context of recursive transformations 
on algebraic data-types (ADTs), it is possible to get the best of both worlds. 
Our first contribution is a new approach to making syntactic templates highly 
reusable by relying on polymorphic synthesis constructs (PSC s). With PSC s, 
a user does not have to write a custom template for every synthesis problem, 
but can instead rely on a generic template from a library. Even when the user 
does write a custom template, the new constructs make this task simpler and 
less error-prone. We show in Section [4] that all our 23 diverse benchmarks are 
synthesized using just 4 different generic templates from the library. Moreover, 
thanks to a carefully designed type-directed expansion mechanism, our generic 
templates provide the same performance benefits during synthesis as conventional, 
program-specific templates. Our second contribution is a new optimization called 
inductive decomposition , which achieves asymptotic improvements in synthesis 
times for large and non-trivial ADT transformations. This optimization, together 
with the user guidance in the form of reusable templates, allows our system to 
attack problems that are out of scope for existing synthesizers. 

We implemented these ideas in a tool called SyntRec, which is built on 
top of the open source Sketch synthesis platform m- Our tool supports ex¬ 
pressive correctness specifications that can use arbitrary functions to constrain 
the behavior of ADT transformations. Like other expressive synthesizers, such 
as Sketch fT5] and Rosette mm, our system relies on exhaustive bounded 
checking to establish whether a program candidate matches the specification. 
While this does not provide correctness guarantees beyond a bounded set of 
inputs, it works well in practice and allows us to tackle complex problems, for 
which full correctness is undecidable and is beyond the state of the art in auto¬ 
matic verification. For example, our benchmarks include desugaring functions 
from an abstract syntax tree (AST) into a simpler AST, where correctness is 
defined in terms of interpreters for the two ASTs. As a result, our synthesizer 
is able to discover Church encodings for pairs and booleans, given nothing but 
an interpreter for the lambda calculus. In another benchmark, we show that the 
system is powerful enough to synthesize a type constraint generator for a simple 
programming language given the semantics of type constraints. Additionally, 
several of our benchmarks come from transformation passes implemented in our 
own compiler and synthesizer. 

2 Overview 

In this section, we use the problem of desugaring a simple language to illustrate 
the main features of SyntRec. Specifically, the goal is to synthesize a function 
dstAST desugar(srcAST src){. ..}, which translates an expression in source AST into 
a semantically equivalent expression in destination AST. Data type definitions 
for the two ASTs are shown in Figure [l] the type srcAST has five variants (two 
of which are recursive), while dstAST has only three. In particular, the source 
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adt srcAST{ adt dstASTj 

NumS{ int v; } NumD{ int v; } 

TrueS{ } BoolD{ bit v; } 

FalseS{ } BinaryD{ opcode op; dstAST a; dstAST b;}} 

BinaryS{ opcode op; srcAST a; srcAST b;} 

BetweenSj srcAST a; srcAST b; srcAST c;}} adt opcode{ AndOp{} OrOp{} LtOp{}} 

Fig. 1: ADTs for two small expression languages 

language construct BetweenS(a, b, c), which denotes a < b < c, has to be desugared 
into a conjunction of two inequalities. Like case classes in Scala, data type variants 
in SyntRec have named fields. 

Specification. The first piece of user input required by the synthesizer is the 
specification of the program’s intended behavior. In the case of desugar, we would 
like to specify that the desugared AST is semantically equivalent to the original 
AST, which can be expressed in SyntRec using the following constraint: 

assert ( srclnterpret (exp) == dstlnterpret(desugar(exp)) ) 

This constraint states that interpreting an arbitrary source-language expression exp 
(bounded to some depth) must be equivalent to desugaring exp and interpreting the 
resulting expression in the destination language. Here, srclnterpret and dstlnterpret 
are regular functions written in SyntRec and defined recursively over the 
structure of the respective ASTs in a straightforward manner. As we explain 
in Section |3.4| our synthesizer contains a novel optimization called inductive 
decomposition that can take advantage of the structure of the above specification 
to significantly improve the scalability of the synthesis process. 

Templates. The second piece of user input required by our system is a syntactic 
template , which describes the space of possible implementations. The template 
is intended to specify the high-level structure of the program, leaving low-level 
details for the system to figure out. In that respect, SyntRec follows the SyGuS 
paradigm [2|; however, template languages used in existing SyGuS tools, such as 
Sketch or Rosette, work poorly in the context of recursive ADT transformations. 

For example, Figure [2] shows a template for desugar written in Sketch, the 
predecessor of SyntRec. It is useful to understand this template as we will show, 
later, how the new language features in SyntRec allow us to write the same 
template in a concise and reusable manner. This template uses three kinds of 
synthesis constructs already existing in Sketch: a choice (choose(ei,...,e n )) must 
be replaced with one of the expressions e±,.. ., e„; a hole (??) must be replaced 
with an integer or a boolean constant; finally, a generator (such as rcons) can 
be thought of as a macro, which is inlined on use, allowing the synthesizer to 
make different choices for every invocatiorjf] The task of the synthesizer is to fill 
in every choice and hole in such a way that the resulting program satisfies the 
specification. 

t Recursive generators, such as rcons, are unrolled up to a fixed depth, which is a 
parameter to our system. 
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dstAST desugar(srcAST src){ 
switch(src) { 
case NumS: 
return rcons(src .v); 

... /* Some cases are elided */ 

case BinaryS: 

dstAST a = desugar(src.a), b = desugar(src.b); 
return rcons(choose(a, b, src.op)); 
case BetweenS: 

dstAST a = desugar(src.a), b = desugar(src.b), 
c = desugar(src.c); 
return rcons(choose(a, b, c)); 


generator dstAST rcons(fun e) { 
if (??) return e(); 
if (??) { 

int val = choose(e(), ??); 

return new NumD(v = val); } 
if (??) { 

bit val = choose(e(), ??); 

return new BoolD(v = val);} 
if (??) { 

dstAST a = rcons(e); 

dstAST b = rcons(e); 

opcode op = choose(e(), new AndOp(),..., 
new LtOpQ); 

return new BinaryD(op = op, a= a, b = b);} 

} 


Fig. 2: Template for desugar in Sketch 

The template in Figure [2] expresses the intuition that desugar should recursively 
traverse its input, src, replacing each node with some subtree from the destina¬ 
tion language. These destination subtrees are created by calling the recursive, 
higher-order generator rcons (for “recursive constructor”), rcons(e) constructs a 
nondeterministically chosen variant of dstAST, whose fields, depending on their 
type, are obtained either by recursively invoking rcons, by invoking e (which is 
itself a generator), or by picking an integer or boolean constant. For example, 
one possible instantiation of the template rcons(choose(x, y, src .op)) [^] can lead to 
new BinaryDfop = src.op, a = x, b = new NumD(5)). Note that the template for desugar 
provides no insight on how to actually encode each node of scrAST in terms of 
dstAST, which is left for the synthesizer to figure out. Despite containing so little 
information, the template is very verbose: in fact, more verbose than the full 
implementation! More importantly, this template cannot be reused for other 
synthesis problems, since it is specific to the variants and fields of the two data 
types. Expressing such a template in Rosette will be similarly verbose. 


Reusable Templates. SyntRec addresses this problem by extending the tem¬ 
plate language with polymorphic synthesis constructs (PSC s), which essentially 
support parametrizing templates by the structure of data types they manipulate. 
As a result, in SyntRec the end user can express the template for desugar with a 
single line of code: 

dstAST desugar(srcAST src) { return recursiveReplacer (src , desugar); } 

Here, recursiveReplacer is a reusable generator defined in a library; its code is 
shown in Figure [3] When the user invokes recursiveReplacer (src .desugar), the body 
of the generator is specialized to the surrounding context, resulting in a template 
very similar to the one in Figure [2] Unlike the template in Figure [2} however, 
recursiveReplacer is not specific to srcAST and dstAST, and can be reused with no 

* When an expression is passed as an argument to a higher-order function that expects 
a function parameter such as rcons, it is automatically casted to a generator lambda 
function. Hence, the expression will only be evaluated when the higher-order function 
calls the function parameter and each call can result in a different evaluation. 
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1 generator T recursiveReplacer <T, Q>(Q src, 

2 fun rec) { 

3 switch (src){ 

4 case?: 

5 T[ ] a = map(src. fields?, rec); 

6 return rcons(choose(a[??], 

7 field (src ))); 

» }}} 

9 generator T rcons<T>(fun e) { 

10 if (??) return e(); 

11 else return new cons?(rcons(e)); 

12 } 

13 generator T field <T,S>(S e) { 

1 4 return (e. fields?) [??]; 

15 } 


1 dstAST desugar(srcAST src) { 

2 switch (src) { 

3 case NumS: return new NumD(v = src.v); 

4 case TrueS: return new BoolD(v = 1); 

5 case FalseS: return new BoolD(v = 0); 

6 case BinaryS: 

7 dstAST[2] a = {desugar(src.a), desugar(src . b)}; 

8 return new BinaryD(op = src.op, a = a [1], 

9 b = a [2]); 
io case BetweenS: 


12 

13 

14 

15 


16 


18 }} 


dstAST[3] a = {desugar(src.a), desugar(src . b), 
desugar(src . c)}; 

return new BinaryD(op = new AndOp(), 
a - new BinaryD(op = new LtOp(), a = a[0], 
b = a[l]) 

b - new BinaryD(op = new LtOp(), a = a[l], 
b = a [2])); 


Fig. 3: Left: Generic template for recursiveReplacer Right: Solution to the running 
example 


modifications to synthesize desugaring functions for other languages, and even 
more general recursive ADT transformations. Crucially, even though the reusable 
template is much more concise than the Sketch template, it does not increase 
the size of the search space that the synthesizer has to consider, since all the 
additional choices are resolved during type inference. Figure [3] also shows a 
compacted version of the solution for desugar, which SyntRec synthesizes in 
about 8s. The rest of the section gives an overview of the PSC s used in Figure |3j 


Polymorphic Synthesis Constructs. Just like a regular synthesis construct, 
a PSC represents a set of potential programs, but the exact set depends on 
the context and is determined by the types of the arguments to a PSC and its 
expected return type. SyntRec introduces four kinds of PSC s. 

1. A Polymorphic Generator is a polymorphic version of a Sketch genera¬ 
tor. For example, recursiveReplacer is a polymorphic generator, parametrized by 
types T and Q. When the user invokes recursiveReplacer (src .desugar), T and Q are 
instantiated with dstAST and srcAST, respectively. 

2. Flexible Pattern Matching (switch(x) case?: e) expands into pattern match¬ 
ing code specialized for the type of x. In our example, once Q in recursiveReplacer 
is instantiated with srcAST, the case? construct in Line [4] expands into five cases 
(case NumS, ..., case BetweenS) with the body of case? duplicated inside each of 
these cases. 

3. Field List (e. fields? ) expands into an array of all fields of type r in a particular 
variant of e, where r is derived from the context. Going back to Figure [3| Line 
[5] inside recursiveReplacer maps a function rec over a field list src. fields? ; in our 
example, rec is instantiated with desugar, which takes an input of type srcAST. 
Hence, SyntRec determines that src. fields? in this case denotes all fields of type 
srcAST. Note that this construct is expanded differently in each of the five cases 
that resulted from the expansion of case?. For example, inside case NumS, this 
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construct expands into an empty array (NumS has no fields of type srcAST), while 
inside case BetweenS, it expands into the array {src.a, src.b, src.c}. 

4. Unknown Constructor (new cons?(ei, expands into a constructor 

for some variant of type r, where r is derived from the context, and uses the 
expressions e\,...,e n as the fields. In our example, the auxiliary generator rcons 
uses an unknown constructor in Line m When rcons is invoked in a context that 
expects an expression of type dstAST, this unknown constructor expands into 
choose(new NumD(...), new BoolD(...), new BinaryD(...)). If instead rcons is expected to 
return an expression of type opcode, then the unknown constructor expands into 
choose(new AndOp(),...,new LtOpQ). If the expected type is an integer or a boolean, 
this construct expands into a regular Sketch hole (??). 

Even though the language provides only four PSC s, they can be combined in 
novel ways to create richer polymorphic constructs that can be used as library 
components. The generators field and rcons in Figure [3] are two such components. 

The field component expands into 
an arbitrary field of type r, where r 
is derived from the context. Its im¬ 
plementation uses the field list PSC 
to obtain the array of all fields of 
type r, and then accesses a random 
element in this array using an inte¬ 
ger hole. For example, if field (e) is 
used in a context where the type of 
e is BetweenS and the expected type 
is srcAST, then field (e) expands into 
(e.a, e.b, e.c}[??] which is semantically 
equivalent to choose(e.a, e.b, e.c). 

The rcons component is a polymor¬ 
phic version of the recursive construc¬ 
tor for dstAST in Figure [2] and can pro¬ 
duce ADT trees of any type up to a 
certain depth. Note that since rcons is 
a polymorphic generator, each call to 
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prim 

f 


= {adti}i {fi}i 

= adt name { varianti... variant n } 

= name {l± : T\ ... l n : r n } 

= r | T | 9[] | fun | 9^9 2 
= prim | name \ : n} i<n 

| E namei{li :rZ} k<ni 
= bit | int 

= 71 / 1 / 

= T ou t name ({a* : t*}*) e 
= generator T out name({xt : Ti}i) e 
= generator 9 ou t name({Ti}i ) ({Xi : 9i}i ) e 
= e | e | e 

= x | let x : 9 = e\ in e 2 | /(e) 

| switch MI case namei : 

| e.l | new name{{li = e*}*) 

I {{e*}t} I ei[e 2 ] I assert (e) 

= ?? | choose({ei}i)l /(e) 

= m new cons?({ej}f) 

e. fields? | switch MI case? : e} 


I 

Fig. 4: Kernel language 

s in the argument to the unknown 
constructor (Line [Tl]) is specialized based on the type required by that construc¬ 
tor and can make different non-deterministic choices. Similarly, it is possible to 
create other generic constructs such as iterators over arbitrary data structures. 
Components such as these are expected to be provided by expert users, while 
end users treat them in the same way as the built-in PSC s. The next section 
gives a formal account of the SyntRec’s language and the synthesis approach. 


3 SyntRec Formally 
3.1 Language 

Figure [4] shows a simple kernel language that captures the relevant features of 
SyntRec. In this language, a program consists of a set of ADT declarations 
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followed by a set of function declarations. The language distinguishes between a 

standard function /, a generator / and a polymorphic generator f. Functions can 
be passed as parameters to other functions, but they are not entirely first-class 
citizens because they cannot be assigned to variables or returned from functions. 
Function parameters lack type annotations and are declared as type fun, but 
their types can be deduced from inference. Similarly, expressions are divided into 
standard expressions that does not contain any unknown choices (e), existing 
synthesis constructs in Sketch (e), and the new PSC s (e). The language also 
has support for arrays with expressions for array creation ({ei, e 2 ,..., e„}) and 
array access (ei[e 2 ]). An array type is represented as 9[ ]. In this formalism, we 
use the Greek letter r to refer to a fully concrete type and 9 to refer to a type 
that may involve type variables. The distinction between the two is important 
because PSC s can only be expanded when the types of their context are known. 
We formalize ADTs as tagged unions r = y variantj , where each of the variants 
is a record type varianti = namei {l\ : Tj,} k<n . Note that ADTs in SyntRec 
are not polymorphic. The notation {di}i is used to denote the {ai,a 2 ,...}. 


3.2 Synthesis Approach 


Given a user-written program P that can potentially contain PSC s, choices and 
holes, and a specification, the synthesis problem is to find a program P in the 
language that only contains standard expressions (e) and functions (/). SyntRec 
solves this problem using a two step approach as shown below.: 


P 

( PSCs, choices 
and holes) 


Type-Directed 

Expansion 

Rules 


P 

(choices ' 
and holes) 


Constraint- 

based 

Synthesis 


P 

(no synthesis 
constructs) 


First, SyntRec uses a set of expansion rules that uses bi-directional type 
checking to eliminate the PSC s. The result is a program that only contains 
choices and holes. The second step is to use a constraint-based approach to solve 
for these choices. The next subsections will present each of these steps in more 
detail. 


3.3 Type-Directed Expansion Rules 

We will now formalize the process of specializing and expanding the PSC s into 
sets of possible expressions. We should first note that the expansion and the 
specialization of the different PSC s interact in complex ways. For example, for 
the case? construct in the running example, the system cannot determine which 
cases to generate until it knows the type of src, which is only fixed once the 
polymorphic generator for recursiveReplacer is specialized to the calling context. 
On the other hand, if a polymorphic generator is invoked inside the body of 
a case? (like rcons in the running example), we may not know the types of the 
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arguments until after the case? is expanded into separate cases. Because of this, 
type inference and expansion of the PSC s must happen in tandem. 

We formalize the process of expanding PSC s using two different kinds of 
judgements. The typing judgement P \~ e : 9 determines the type of an expression 
by propagating information bottonr-up from sub-expressions to larger expressions. 
On the other hand, PSC s cannot be type-checked in a bottom-up manner; 
instead, their types must be inferred from the context. The expansion judgment 
The —> e! expands an expression e involving PSC s into an expression e' that 
does not contain PSC s (but can contain choices and holes). In this judgment, 
6 is used to propagate information top-down and represents the type required 
in a given context; in other words, after this expansion, the typing judgement 
r h e! : 9 must hold. We are not the first to note that bi-directional typing |15| 
can be very useful in pruning the search space for synthesis mm, but we are the 
first to apply this in the context of constraint-based synthesis and in a language 
with user-provided definitions of program spaces. 


FUN 


r-{xi ■■n} i he 


rhTo f ({Xi : Ti} i<n ) e > To f ({Xi : Ti} i<n ) e 


FL 


r h e : {h : n} i<n r he 1 ' e { Tij = ro}j (to[ ] = r) 


FPM 


UC1 


r b e. fields? —> {{e 

r = (V;x : E namei {lj : r£} fc<n ,) _ : {lj : r£} fc<n .) h e 

r b switch (ic) { case? : e } —>■ switch ( x ) { case namei ■ ^i}i 

t = Enamei {l\ : r k } k<n 
r b new cons? (ei ... e m ] 


6 l fc • • • Crr 


choose 


({new name i ({4 = choose ({ e' rh } r <m iiCJJj 


UC2 


r = prim 


r b new cons? (ei ... e m ) —> ?? 


Qout f ({Ti}) ({ Pi : Oi},) e Tl-eurt fori <k 

S = Unify ({(fl out , 0)} U {{e t ,rt)} i<k ) 

ei l6 ' ’> e'i for i < k + n e [Wi / Pi] i] — ~> e' 

/ (eo ■ • • e k ... e k +n) —> e! 

Fig. 5: Expansion rules for various language constructs 


PG 


The expansion rules for functions and PSC s are shown in Figure[5] At the top 
level, given a program P, every function in P is transformed using the expansion 
rule FUN. The body of the function is expanded under the known output type 
of the function. The most interesting cases in the definition of the expansion 
judgment correspond to the PSC s as outlined below. The expansion rules for the 
other expressions are straightforward and are elided for brevity. 
















Field List The rule FL shows how a field list is expanded. If the required type 
is an array of r 0 , then this PSC can be expanded into an array of all fields of 
type r 0 . 

Flexible Pattern Matching For each case, the body of case? is expanded while 
setting x to a different type corresponding to each variant namet {l l k : T l} k<n as 
shown in the rule FPM. Here, the argument to switch is required to be a variable 
so that it can be used with a different type inside each of the different cases. Note 
that each case is expanded independently, so the synthesizer can make different 
choices for each ey. 

Unknown constructor If the required type is an ADT, the rule UC1 expands 
the expressions passed to the unknown constructor based on the type of each 
field of each variant of the ADT and uses the resulting expressions to initialize 
the fields in the relevant constructor. It returns a choose expression with all these 
constructors as the arguments. If the required type is a primitive type (int or 
bit), the unknown constructor is expanded into a Sketch hole by the rule UC2. 
Polymorphic Generator Calls When the expansion encounters a call to a 
polymorphic generator, the generator will be expanded and specialized according 
to the PG rule. When a generator is called with arguments {e^, we can separate 
the arguments into expressions that can be typed using the standard typing 
judgement, and expressions such as new cons? (...) that cannot. In the rule, we 
assume, without loss of generality, that the first k expressions can be typed and 
the reminder cannot. The basic idea behind the expansion is as follows. First, 
the rule obtains the types of the first k arguments and unifies them with the 
types of the formal parameters of the function to get a type substitution S. The 
arguments to the original call are expanded with our improved knowledge of the 
types, and the body of the generator is then inlined and expanded in turn. The 
actual implementation also keeps track of how many times each generator has 
been inlined and replaces the generator invocation with assert false when the 
inlining bound has been reached. 

The above expansion rules fail if a type variable is encountered in places 
where a concrete type is expected, and in such cases the system will throw an 
error. For example, expressions such as field (field (e)), where field is as defined 
in Figure [3] cannot by type-checked in our system because the expected type of 
the inner field call cannot be determined using top-down type propagation. 

3.4 Constraint-based Synthesis 

Once we have a program with a fixed number of integer unknowns, the synthesis 
problem can be encoded as a constraint 3<p. Vcr. P{(f>, cr) where cf> is a control 
vector describing the set of choices that the synthesizer has to make, a is the 
input state of the program, and P(</>, cr) is a predicate that is true if the program 
satisfies its specification under input cr and control cf>. Our system follows the 
standard approach of unrolling loops and inlining recursive calls to derive P and 
uses counterexample guided inductive synthesis (CEGIS) to solve this doubly 
quantified problem m- For readers unfamiliar with this approach, the most 
relevant aspect from the point of view of this paper is that the doubly quantified 
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problem is reduced to a sequence of inductive synthesis steps. At each step, 
the system generates a solution that works for a small set of inputs, and then 
checks if this solution is in fact correct for all inputs; otherwise, it generates a 
counter-example for the next inductive synthesis step. 

Applying the standard approach can, however, be problematic in our context 
especially with regards to inlining recursive calls. For instance, consider the 
example from Section [2] Here, the function desugar that has to be synthesized is a 
recursive function. If we were to inline all the recursive calls to desugar, then a given 
concrete value for the input a such as BetweenS(a = NumS(...), b = BinaryS(...), ...) , 
will exercise multiple cases within desugar (BetweenS, NumS and BinaryS for the 
example). This is problematic in the context of CEGIS, because at each inductive 
synthesis step the synthesizer has to jointly solve for all these variants of desugar 
which greatly hinders scalability when the source language has many variants. 


3.5 Inductive Decomposition 

The goal of this section is to leverage the inductive specification to potentially 
avoid inlining the recursive calls to the synthesized function. This idea of treating 
the specification as an inductive hypothesis is well known in the deductive verifi¬ 
cation community where the goal is to solve the following problem: Vcr. P((f>o,a). 
However, in our case, we want to apply this idea during the inductive synthesis 
step of CEGIS where the goal is to solve 3 <fi. P(<j>, <To) which has not been explored 
before. 


Definition 1 (Inductive Decomposition). Suppose the specification is of 
the form interp s (e) = interpd(trans(e )) where trans is the function that needs 
to be synthesized. Let trans(e') be a recursive call within trans(e) where e! is 
strictly smaller term than e. Inductive Decomposition is defined as the following 
substitution: 1. Replace trans(e') with a special expression e' . 2. When inlining 


function calls, apply the following rules for the evaluation of 


interpd( e' )- > interp s {e') 

in any other context - > transie') 


i.e. Inductive Decomposition works by delaying the evaluation of a recursive 
trans(e') call by replacing it with a placeholder that tracks the input e!. Then, 
if the algorithm encounters these placeholders when inlining interpd in the 
specification, it replaces them directly with interp s (e') which we know how 
to evaluate, thus, eliminating the need to inline the unknown trans function. 
This replacement is sound because the specification states interpd(trans{e')) = 
interp s (e'). If the algorithm encounters the placeholders in any other context 
where the inductive specification can not be leveraged, it defaults to evaluating 
trans(e'). 


Theorem 1. Inductive Decomposition is sound and complete. In other words, 
if the specification is valid before the substitution, then it will be valid after the 
substitution and vice-versa. 
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A proof of this theorem can be found in the tech report [6]. Although the 
Inductive Decomposition algorithm imposes restrictions on which recursive calls 
can be eliminated, it turns out that for many of the ADT transformation scenarios, 
the algorithm can totally eliminate all recursive calls to trans. For instance, in the 
running example, because of the inductive structure of dstlnterpret , all placeholders 
for recursive desugar calls will occur only in the context of dstlnterpret (desugar(e')) 
which can be replaced by srclnterpret (e’) according to the algorithm. Thus, after 
the substitution, the desugar function is no longer recursive and moreover, the 
desugaring for the different variants can be synthesized separately. For the 
running example, we gain a 20X speedup using this optimization. Our system 
also implements several generalizations of the aforementioned optimization that 
are detailed in the tech report [6j. 


4 Evaluation 


Benchmarks We evaluated our approach on 23 benchmarks as shown in Figure[6j 
All benchmarks along with the synthesized solutions can be found in the tech 
report [B] . Since there is no standard benchmark suite for morphism problems, we 
chose our benchmarks from common assignment problems (the lambda calculus 
ones), desugaring passes from Sketch compiler and some standard data structure 
manipulations on trees and lists. The AST optimization benchmarks are from a 
system that synthesizes simplification rules for SMT solvers da. 


Templates The templates for all our benchmarks use one of the four generic 
descriptions we have in the library. All benchmarks except arrAssertions , NegNorm 
and AST optimizations use a generalized version of the recursiveReplacer generator 
seen in Figure [3] (the exact generator is in the tech report). This generator is 
also used as a template for problems that are very different from the desugaring 
benchmarks such as the list and the tree manipulation problems, illustrating 
how generic and reusable the templates can be. The arrAssertions benchmark 
differs slightly from the others as its ADT definitions have arrays of recursive 
fields and hence, we have a version of the recursive replacer that also recursively 
iterates over these arrays. The NegNorm benchmark requires a template that has 
nested pattern matching. Another interesting example of reusability of templates 
is the AST optimization benchmarks. All 5 benchmarks in this category are 
synthesized from a single library function. The template column in Figure [6] shows 
the number of lines used in the template for each benchmark. Most benchmarks 
have a single line that calls the appropriate library description similar to the 
example in Section [2] Some benchmarks also specify additional components such 
as helper functions that are required for the transformation. Note that these 
additional components will also be required for other systems such as Leon and 
Synquid. 
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4.1 Experiments 

Methodology All experiments were run on a machine with forty 2.4 GHz Intel 
Xeon processors and 96GB RAM. We ran each experiment 10 times and report 
the median. 

Hypothesis 1: Synthesis of complex routines is possible Figure [6] shows 
the running times for all our benchmarks (T-opt column). SyntRec can syn¬ 
thesize all but one benchmark very efficiently when run on a single core using 
less than 1GB memory—19 out of 23 benchmarks take < 1 minute. Many of 
these benchmarks are beyond what can be synthesized by other tools like Leon, 
Rosette, and others and yet, SyntRec can synthesize them just from very general 
templates. For instance, the IcB and IcP benchmarks are automatically discovering 
the Church encodings for boolean operations and pairs, respectively. The tc 
benchmark synthesizes an algorithm to produce type constraints for lambda 
calculus ASTs to be used to do type inference. The output of this algorithm is a 
conjunction of type equality constraints which is produced by traversing the AST. 
Several other desugaring benchmarks have specifications that involve complicated 
interpreters that keep track of state, for example. Some of these specifications 
are even undecidable and yet, SyntRec can synthesize these benchmarks (up to 
bounded correctness guarantees). The figure also shows the size of the synthesized 
solution (code column)^] 

There is one benchmark (langState) that cannot be solved by SyntRec using 
a single core. Even in this case, SyntRec can synthesize the desugaring for 6 out 
of 7 variants in less than a minute. The unresolved variant requires generating 
expression terms that are very deep which exponentially increases the search 
space. Luckily, our solver is able to leverage multiple cores using the random 
concretization technique [7] to search the space of possible programs in parallel. 
The column T-parallel in Figure [6] shows the running times for all benchmarks 
when run on 16 cores. SyntRec can now synthesize all variants of the langState 
benchmark in about 9 minutes. 

The results discussed so far are obtained for optimal search parameters for 
each of the benchmarks. We also run an experiment to randomly search for 
these parameters using the parallel search technique with 16 cores and report the 
results in the T-search column. Although these times are higher than when using 
the optimal parameters for each benchmark (T-parallel column), the difference is 
not huge for most benchmarks. 

Hypothesis 2: The Inductive Decomposition improves the scalability. 

In this experiment, we run each benchmark with the Inductive Decomposition 
optimization disabled and the results are shown in Figure [6] (T— unopt column). 
This experiment is run on a single core. First of all, the technique is not applicable 
for the AST optimization benchmarks because the functions to be synthesized 
are not recursive. Second, for three benchmarks—the A-calculus ones and the 
tc benchmark, we noticed that their specifications do not have the inductive 
structure and hence, the optimization never gets triggered. 

§ Solution size is measured as the number of nodes in the AST representation of the 
solution 
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Bench 

Description 

template code 

T-opt T-parallel T-search T-unopt 


lang 

Running example 

i 

50 

7.5 

8.6 

85.9 

152.5 


langState 

Running example with mutable state 

i 

62 

X 

527.2 

1746.9 

X 


regex 

Desugaring regular expressions 

i 

22 

2.0 

3.3 

9.1 

3.3 

a 

elimBool 

Boolean operations to if else 

i 

21 

1.5 

2.9 

7.5 

2.4 


compAssign 

Eliminates compound assignments 

i 

42 

16.6 

20.9 

31.8 

176.2 

(V 

n 

langLarge 

Desugaring a large language 

i 

126 

61.2 

58.0 

49.7 

X 


arr Assertions 

Add out of bounds assertions 

3 

40 

37.2 

50.5 

66.7 

53.0 


NegNorm 

Computes negation normal form 

3 

57 

21.2 

13.6 

64.4 

X 


lcB 

Boolean operations to A-calculus 

1 

55 

43.1 

47.4 

40.6 

43.1 


lcP 

Pairs to A-calculus 

1 

41 

163.6 

258.2 

288.3 

163.6 

~n. 

It 

tc 

Type constraints for A-calculus 

8 

41 

168.9 

68.0 

201.9 

168.9 

g 

andLt 

AST optimization 1 

1 

15 

3.1 

3.1 

13.2 

N/A 


andNot 

AST optimization 2 

1 

6 

2.6 

3.0 

13.0 

N/A 

o 

andOr 

AST optimization 3 

1 

12 

3.7 

3.1 

14.0 

N/A 

H 

CO 

plusEq 

AST optimization 4 

1 

18 

3.3 

3.0 

14.0 

N/A 

< 

mux 

AST optimization 5 

1 

6 

2.4 

3.0 

12.4 

N/A 


llns 

List insertion 

1 

12 

1.5 

2.3 

2.2 

2.1 

.a 

IDel 

List deletion 

2 

14 

4.0 

4.6 

4.1 

3.1 


lUnion 

Union of two lists 

1 

10 

8.7 

2.7 

4.8 

2.1 


tins 

Binary search tree insertion 

1 

48 

20.7 

14.5 

41.6 

11.6 

<D 

0) 

tDel 

Binary search tree deletion 

4 

63 

224.8 

227.4 

286.1 

298.9 

£ 

tDelMin 

Binary search tree delete min 

2 

18 

27.1 

32.2 

57.7 

24.9 


tDelMax 

Binary search tree delete max 

2 

18 

25.9 

30.8 

54.4 

25.9 


Fig. 6: Benchmarks. All reported times are in seconds. _L stands for timeout (> 
45 min) and N/A stands for not applicable. 


But for the other benchmarks, it can be seen that inductive decomposition 
leads to a substantial speed-up on the bigger benchmarks. Three benchmarks 
time out (> 45 minutes) and we found that langState times out even when run in 
parallel. In addition, without the optimization, all the different variants need to 
be synthesized together and hence, it is not possible to get partial solutions. The 
other benchmarks show an average speedup of 2X with two benchmarks having 
a speedup > 10X. We found that for benchmarks that have very few variants, 
such as the list and the tree benchmarks, both versions perform almost similarly. 

To evaluate how the performance depends on the number of variants in the 
initial AST, we considered the langLarge benchmark that synthesizes a desugaring 
for a source language with 15 variants into a destination language with just 4 
variants. We started the benchmark with 3 variants in the source language while 
incrementally adding the additional variants and measured the run times both with 
the optimization enabled and disabled. The graph of run time against the number 
of variants is shown in Figure [7] It can be seen that without the optimization 
the performance degrades very quickly and moreover, the unoptimized version 
times out (> 45 min) when the number of variants is > 11. 


4.2 Comparison to other tools 

We compared SyntRec against three tools—Leon, Synquid and Rosette that 
can express our benchmarks. The list and the tree benchmarks are the typical 
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benchmarks that Leon and Synquid can solve and they are faster than us on 
these benchmarks. However, this difference is mostly due to SyntRec’s final 
verification time. For these benchmarks, our verification is not at the state of the 
art because we use a very naive library for the set related functions used in their 
specifications. We also found that Leon and Synquid can synthesize some of our 
easy desugaring benchmarks that requires constructing relatively small ADTs 
like elimBool and regex in almost the same time as us. However, Leon and Synquid 
were not able to solve the harder desugaring problems including the running 
example. We should also note that this comparison is not totally apples-to-apples 
as Leon and Synquid are more automated than SyntRec. 

For comparison against Rosette, we 
should first note that since Rosette is 
also a SyGus solver, we had to write 
very verbose templates for each bench¬ 
mark. But even then, we found that 
Rosette cannot get past the compi¬ 
lation stage because the solver gets 
bogged down by the large number 
of recursive calls requiring expansion. 

For the other smaller benchmarks that 
were able to get to the synthesis stage, 
we found that Rosette is either com¬ 
parable or slower than SyntRec. For 
example, the benchmark elimBool takes 
about 2 minutes in Rosette compared 
to 2s in SyntRec. We attribute these 
differences to the different solver level 
choices made by Rosette and Sketch 
(which we used to built SyntRec upon). 



Fig. 7: Run time (in seconds) versus the 
number of variants of the source lan¬ 
guage for the langLarge benchmark with 
and without the optimization. 


5 Related Work 

There are many recent systems that synthesize recursive functions on algebraic 
data-types. Leon mm and Synquid m are two systems that are very close 
to ours. Leon, developed by the LARA group at EPFL, is built on prior work 
on complete functional synthesis by the same group m and moreover, their 
recent work on Synthesis Modulo Recursive Functions [8] demonstrated a sound 
technique to synthesize provably correct recursive functions involving algebraic 
data types. Unlike our system, which relies on bounded checking to establish 
the correctness of candidates, their procedure is capable of synthesizing provably 
correct implementations. The tradeoff is the scalability of the system; Leon 
supports using arbitrary recursive predicates in the specification, but in practice 
it is limited by what is feasible to prove automatically. Verifying something like 
equivalence of lambda interpreters fully automatically is prohibitively expensive, 
which puts some of our benchmarks beyond the scope of their system. Synquid |16j . 
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on the other hand, uses refinement types as a form of specification to efficiently 
synthesize programs. Like our system, Synquid also depends on bi-directional type 
checking to effectively prune the search space. But like Leon, it is also limited to 
decidable specifications. There has also been a lot of recent work on programming 
by example systems for synthesizing recursive programs |1MU14|. All of these 
systems rely on explicit search with some systems like m using bi-directional 
typing to prune the search space and other systems like [1] using specialized 
data-structures to efficiently represent the space of implementations. However, 
they are limited to programming-by-example settings, and cannot handle our 
benchmarks, especially the desugaring ones. 

Our work builds on a lot of previous work on SAT/SMT based synthesis 
from templates. Our implementation itself is built on top of the open source 
Sketch synthesis system |18j . However, several other solver-based synthesizers 
have been reported in the literature, such as Brahma [5] . More recently, the work 
on the solver aided language Rosette mm has shown how to embed synthesis 
capabilities in a rich dynamic language and then how to leverage these features 
to produce synthesis-enabled embedded DSLs in the language. Rosette is a very 
expressive language and in principle can express all the benchmarks in our paper. 
However, Rosette is a dynamic language and lacks static type information, so in 
order to get the benefits of the high-level synthesis constructs presented in this 
paper, it would be necessary to re-implement all the machinery in this paper as 
an embedded DSL. 

There is also some related work in the context of using polymorphism to 
enable re-usability in programming. EH is one such approach where the authors 
describe a design pattern in Haskell that allows programmers to express the 
boilerplate code required for traversing recursive data structures in a reusable 
manner. This paper, on the other hand, focuses on supporting reusable templates 
in the context of synthesis which has not been explored before. Finally, the 
work on hole driven development EH is also related in the way it uses types to 
gain information about the structure of the missing code. The key difference 
is that existing systems like Agda lack the kind of symbolic search capabilities 
present in our system, which allow it to search among the exponentially large 
set of expressions with the right structure for one that satisfies a deep semantic 
property like equivalence with respect to an interpreter. 


6 Conclusion 

The paper has shown that by combining type information from algebraic data¬ 
types together with the novel Inductive Decomposition optimization, it is possible 
to efficiently synthesize complex functions based on pattern matching from 
very general templates, including desugaring functions for lambda calculus that 
implement non-trivial Church encodings. 

Acknowledgments: We would like to thank the authors of Leon and Rosette 
for their help in comparing against their systems and the reviewers for their 
feedback. This research was supported by NSF award $=1139056 (ExCAPE). 
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A Benchmarks and Library Components 


All the benchmarks along with corresponding synthesized solutions can be found 
at https://bitbucket.org/jeevana_priya/syntrec-benchmarks/src. The library 
generators and components are in the lib.skh file in the above repository. The 
solutions generated by SyntRec are a little verbose because of the temporary 
variables and also beacuse the function outputs are converted into reference 
parameters. 


B Static Semantics of SyntRec language 

The typing rules for the language work as one would expect. For example, the 
type of a field access from a record is the type of the field. 

r he: {{k : Tj};} l = li t = n 
r~F e.i-.r 

Values in the ADT are created through constructors. 

T a dt = Snama {{F k : rljkKni} name = name t {h = l k A b e k : rl}k<nt 
F I- new name(lj = ej) : r a dt 

The most interesting rule is the one for switch. The rule, shown below, assumes 
that the argument x to switch is a variable whose type is an ADT where each 
variant corresponds to one of the cases in the switch. The body of each case is 
then type checked under the assumption that the type of x is the type associated 
with the corresponding variant. 

r = (r ;x : Tadt ) Tadt = Snama {{l k : T k }k < ni } 

{{r'-x: {{lj :r/} fc<n ,})h a : r}i 

F b switch ( x) { case namet : e* } i : r 


C Dynamic Semantics of SyntRec language 

The dynamic semantics evaluate expressions under an environment cr that 
tracks the values of variables. ADT values are represented with a named record 
(name, {li = Uj}») that has the name of the corresponding variant and the values 
for each field. This is illustrated by the rule for the constructor. 

{a, e t -> Vi}i v = (name, {k = u j;) 
tr, new name ({h = &;},;) —> v 

The name stored as part of the record is used by the switch statement in order 
to choose which branch to evaluate. 

a (x) = (name, {li = Vi}i) namej = name a, ej —» v 
a, switch (x) { case namei : ej}; v 
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and it is easy to show that the typing rules ensure that the field access rule below 
will always find a matching field l; = l . 

a, e —> (name, {U = v{\i) l = h v = i>j 
a, e.l —» i> 


D Proof of Inductive Decomposition theorem 


The proof has two parts; first we show that the substitution is complete, meaning 
that if the original specification is valid for a given synthesized trans function, 
then it will still be valid after we perform the substitution. Second, we show 
that the substitution is sound i.e. if the original specification does not hold for a 
given trans, then it will also not hold after the substitution. Also note that we 
can assume that there is only one recursive call (trans(e')) that undergoes the 
transformation, because if replacing one call has no effect, then the calls can be 
replaced one by one until all the calls have been replaced. 

Completeness: We start by assuming that the specification is indeed valid for 


a particular trans. In this case, interpd( e ' ) is in fact equivalent to interp s (e') 


(since the specification is valid for all e). Hence, the specification is still valid 
after the substitution. 

Soundness: Let us assume that the specification does not hold, and let e x be 
the smallest ADT value such that interp s ( e x ) ^ interpd(trans ( e x )) . We define 
smallest in terms of the maximum depth of recursion of e x (the height of the tree, 
if we think of e x as a tree). Now, if e x is not recursive, we are done since the 
substitution will only affect recursive values. Now, if e x is recursive and assume 
that there is a recursive trans(e ' x ) that gets replaced by the substitution. Here, 
since e(. is smaller than e x and because e x is the smallest ADT that does not 

1) is still equivalent to interp s (e' x ). Hence, 


satisfy the specification, interpd( 


the substitution has no impact on validity of e x and so, e x will also fail the 
specification. 

Note that the proof of soundness above only works because the recursive calls 
inside trans operate on trees that are smaller than the input tree. This is an 
important condition that is usually enforced by the template; if it were not to 
hold, the transformation could take a buggy implementation (one that has an 
infinite recursion, for example) and make it appear correct. 


E Structural constraints for full application of Inductive 
Decomposition 

Below, we first define the several structural constraints such that if these con¬ 
straints were to hold, then the inductive decomposition will totally eliminate all 
recursive trans calls. 

Definition 2 (Recursive Transformer). 

Given an ADT t = JA Q, ; {/*■ : rj} ^ , a function f is a Recursive Trans¬ 

former if it has the following form: 
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/(e) := switch (e) {case Qi : proc Qi ({/(eJ* fc )} fc<6i , {eJ}-- } fe<b ')} 

Where none of the fields e.lt, are of type r (but all the fields e.l) k must be of 
type t for the recursive call to be well typed). 

In other words, / will pattern match on e, and in each case it will make 
recursive calls on certain fields of e and process the results through an arbitrary 
function proc® 1 before returning them. 

Definition 3 (Recursive Morphism). 

A Recursive Morphism is a Recursive Transformer with the following 
additional constraint: 

proc®*- (vo,... Vk, v' 0 ,..., v' k ) = ip[v o,... Vk\ where vq ... Vk are the terms in¬ 
volving the recursive calls to this morphism function and ’ll: is an expression that 
constructs an ADT tree (potentially of a different type than t) with vq .. .Vk as 
some of the leaves and ip itself does not depend on them, so 
procQ^Uo,... Uk, Vq, ..., v ' k ) = ip[uo, ■ ■ ■ Mfc] with the same ip. 

For example, the desugar function is a recursive morphism where ip for each 
case is the unknown expression tree of type dstAST that is generated by the rcons 
function in the template (line 6 in Figure [3J. On the other hand, the interpreters 
in the running example that compute the value of an expression from the values of 
its sub-expressions are examples of recursive transformers by the above definition, 
but are not morphisms because they read the recursively evaluated values. 

Lemma 1. Let interp s , interpd be two recursive transformers that operate on 
two recursive data types t s = JT Ki \ l) '• t? f and r d = Qi \ '■ T t r 

t J J J j<ni t J J J j<mi 

respectively and they both produce values of type r r . Additionally, suppose trans 
is a recursive morphism from t s to T d . Under these constraints, the inductive 
decomposition optimization will eliminate all recursive trans calls and thus, 
making trans non-recursive. 


F Generalizations of Inductive Decomposition 

Inductive decomposition can be generalized relatively easily to cases when the 
interpreter takes additional arguments. This is useful, for example, for an inter¬ 
preter that must take as input the state of the program in addition to an AST. 
In this case, the specification will have the form 

interp s (e, S) = interpd (trans (e), S ) 

Here, the inductive decomposition can be modified as follows: 

interp d ^ e' | , S) - > interp s (e ', S ) 

This works because we are replacing what would have been a call to interp d (v , S ) 
where v would have been the result of calling trans{e') with a call to interp s [e !, S). 
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A more interesting generalization involves the case when trans(e ) takes some 
parameters. For example, in cases when the transformation is type directed, 
trans may take as a parameter a symbol table which gets updated as part of 
the recursive calls to trans . In that case, the specification will look like the one 
below. 

interp s (e, S ) = interp d (trans (e, F), S) 
assuming F = F(S'); 


Without the constraint that r is a function of S, the specification would almost 
guarantee that trans ignores F, since F only appears on the right-hand side of 
the equality. When trans is a type directed transformation, for example, F would 
produce a symbol table with the types of the variables in the state S. 

In this case, the inductive decomposition algorithm looks as follows: First, 
replace trans(e', F) with the special expression e', F . Second, apply the following 


rules for the evaluation of e', F 


1.interpd(\ 

2 . 


, F 


, S) - > interp s (e r , S') if F = F(S) 

e',r in any other case - >trans(e',r) 


In this case, the placeholder for trans function must thread its extra param¬ 
eter F through its recursive calls, possibly transforming it along the way. The 
transformation of interpd looks much like it did in the previous generalization, 
but in addition to adding a call to to interp s (e ', S), the optimization will also 
have to include an check that F = F(S). We found that for simple interpreters 
and morphisms, this additional check is not a significant constraint; it will hold 
whenever the state of the transformer is some abstraction of the program state (as 
is the case with types). The cases where it does not hold, are cases where the state 
F tracks some aspect of the program that is not tracked by the interpreter, for 
example, whether a given construct has been seen or not. In such cases, however, 
it is relatively easy to extend the interpreter to track this additional aspect as 
part of its state. 
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